"In the previous message, David Dyer-Bennet said..." > > In article <3454@rwing.UUCP> you write: > > >I don't really think that the 8lgm stuff was all fresh, unknown to > >anybody stuff. Betcha that it was ALL well-known to the 'pivileged > >few'. And whether it was reported to CERT is irrelevant. With the > >recent behavior of CERT, they would be one of the LAST people I would > >report a problem I became aware of to (if I wanted to get as many sites > >secured against it as possible as quickly as possible). They might be > >appropriate if I wanted to claim "I reported it" yet ensure a maximum > >delay in fixing it, to ensure as many sites remain vulnerable as long > >as possible for cracker buddies... > > I think CERT should always be included on the mailing list of people you > report a problem to (I mean, if you want to be a good guy and want to get it > fixed). Doing so denies them the out of saying "We didn't know about it." > And who knows, perhaps the horse will learn to sing. Well, I think that CERT is more of a waste of time entity - kinda like mailing to /dev/null. The sort of outfit one can send to if wants to claim they tried to alert people, when in fact one really didn't want to alert the 'good guys'. > I understand the IETF has started an activity to set the operational > parameters of a CERT-replacement. They didn't put it quite so bluntly. Who/what is IETF? Is this a list I should be interested in? > I agree with you about the importance of spreading the information. A few > basic things like not doing public disclosure just before a day that most > commercial admins will be away are probably justifable, but basically I'm in > favor of letting out the information. Assuming I discover a nasty hole, and know how to exploit it: What I have always advocated is a three step procedure. Step one is to let the affected vendor know. How subsequent steps are handled are dependent on the response of the vendor, mostly in the area of influencing time frames. The vendor would be told that disclosure will be happening in a general form, followed by enough info that people can check out their sites. Step two being to give out bare minimums to the net - for example "A serious security problem exists in rdist. Strongly recommend disabling the service for the time being, and contacting your vendor for a patch. Details adequate to test and perhaps devise your own workaround/fix in one or two weeks. Suggest you obtain freeware sources from one of the archive sites and get it ported sufficient to get it to compile in the interim, so applying a fix will be as easy as possible." Then step three is to fire off the full details late Sunday night or early Monday morning a week or two later (depending), to ensure it is in the news spool or mailbox about when the admin gets there in the morning. This would get the info out, and not blind-side anybody. If the vendor came across as really sincere, and asked me to sit on it longer since they were really going to make a fix available, I would tend to comply WITHIN REASON. I would contact them before I was ready to disclose and ask them about the status of their fix. If I got the feeling that they weren't going to do anyting but sit on it, or otherwise stall, I would tell them thats not acceptable, and let them know they got <whatever time interval, determined by complexity> left, as I intend to disclose. As with anything, variations on this basic procedure would be determined by common sense. Something that is due to the design of some major component of the system, being harder to fix, would get a longer delay than somehting that only requires fixing a typo in the source. This would also apply to other problems - like some procedure by which a user could reliably cause a panic and crash, corruption of data, or whatever. But the knowlege that disclosure WOULD occur acts as a disincentive for a vendor to drag their feet on the problem. Otherwise, why hurry, says the vendor - nobody knows about it... I think that is about as balanced an approach as possible. It gives vendors a chance to act, yet doesn't allow anybody to put the problem into a black hole so they don't have to do anything. If someone has a better basic procedure, sound off. The problem is, that invariably it is the larger, high profile sites that will usually spot the holes, since there are more people accessing it, and it is a more lucrative target for crackers to break, and there are more people on the staff to spot a bug. The problem arises because all too often a fair number of the larger site admins know each other, and will trade info privately, perhaps drop a line to the vendor, and tend to disregard the smaller sites and the rest of the world, figuring 'the vendor or CERT will take care of it' since they generally will get the Red Carpet treatment from CERT, so to THEM CERT appears as if its a useful service. They cover THEIR butts, and tend to say 'to hell with everyone else'. These types are easy to recognize - they are the ones who oppose any disclosure (except to them, of course), or only advocate disclosure a couple of decades later.... - -- pat@rwing [If all fails, try: rwing!pat@ole.cdac.com] Pat Myrto - Seattle WA "No one has the right to destroy another person's belief by demanding empirical evidence." -- Ann Landers, nationally syndicated advice columnist and Director at Handgun Control Inc.